The University of Texas at Austin Department of Mechanical Engineering Dissertation Proposal An Empirical Study of Product Functional Families: Analyzing Key Performance Metric Trends to Derive Actionable Design Insights

To satisfy customers and achieve market success, an engineered product must be designed to match the intended application. It is asserted here that successful products in mature markets have followed a set of implicit rules which represent necessary (but not sufficient) criteria for success. This research seeks to discover and document an understanding of some of these implicit rules, and convert them into actionable design insights. The study will begin with reverse engineering the product definition information (customer needs and product requirements) of several carefully selected sets of inter-related products. This product definition information will then be linked to information about the usage context for which each product was designed. Insights gleaned from the analysis of this data will then be made accessible to engineers in the form of: (1) knowledge encapsulation modules providing familiarity with various product design contexts, (2) Ashby-style plots graphically depicting products successful in a given design context in terms of normalized key performance metrics, and (3) a Design by Analogy method indicating trends of how certain functions are often solved based on characteristics of the design context. It is hypothesized that when designing for product needs in a design context outside their experience and expertise, engineers will create more effective designs when equipped with these design insights. This hypothesis will be tested formally through experimentation with design teams. The key contributions expected from this work are: (1) an empirical data set of product definition information linked with usage context, (2) an insightful comparison of products on the basis of normalized key performance metrics, (3) documentation of energy function solutions correlated with the resulting key performance metrics, and (4) documented actionable design insights. Introduction Engineering design may be defined as the process of applying knowledge to define a product which satisfies a human need. Multiple texts have put forward formal design methods (e.g. [1,2,3,4,5]), exhibiting some variations among definitions. For this reason, working definitions are presented here for: product definition, customer needs, and product requirements. The following two sections build on these definitions by introducing and exploring the concept of product design context, with a focus on the context in which a product will be used. The beginning stages of the product design process may be collectively referred to as the “front-end” of the design process [1], “understanding the problem” [2,4], or the “product definition” phase. This beginning phase is characterized by extensive information gathering, and is foundational to creating successful designs. The following definition is used here: Product definition the first phase of the design process including: background research (often including competitive benchmarking), gathering customer needs, and formulating product requirements/engineering specifications. Customer needs (sometimes called “customer requirements”) combined with importance ratings show how important it is to the customer that certain expectations are satisfied. For example, the abbreviated product definition information shown in Table 1 indicates that “boil water” is a must (importance rating of 5) for customer satisfaction, whereas the need “economical to buy” is desirable but negotiable. Product requirements (sometimes called “engineering specifications,” “design requirements,” or “functional requirements”) define quantitative measures for satisfaction of customer needs. A product requirement consists of a metric such as mass (kg) or cost ($) combined with a design target value (or thresholds of satisfaction) as shown in Table 1. Quality Function Deployment (QFD) is a popular format for displaying the translation of customer needs into product requirements, along with benchmarking information from competing products in order to aid in setting design targets (as shown in Figure 3 on page 9). * A Kano diagram represents a product requirement threshold as the origin of the axes, the point at which the degree of implementation is great enough to cross from negative to positive customer satisfaction. It also shows the effect of exceeding or undershooting the product requirement thresholds depending on whether a need is classified as basic, expected, or delighted. Table 1: Abridged Product Definition for a Portable Stove. Customer Needs Importance Product Requirements Boil water 5 Heat into water ≥ 1 kW Portable 5 Total mass ≤ 20 kg Volume ≤ 5000 cm Largest dimension ≤ 25 cm Economical to buy 3 Total cost ≤ $20 . . . Key performance metrics refers here to the product requirements critical to fulfilling the top customer needs. Customers are likely to be delighted with products that perform well in terms of these key metrics, and disgusted if products perform poorly. The product requirements shown in Table 1 are all key performance metrics; if the stove performs poorly in any of these areas customers will not be satisfied. Other requirements for the portable stove such as “weather proof,” thought still important to the customer, have far less influence on overall satisfaction. Product Design Context This research seeks to augment current design methods for the product definition phase by explicitly accounting for the design context in which a product will be used. Product design context all environmental factors that may significantly affect the design of a product. These factors may be divided into three categories: customer context, market context, and usage context. The three groups of factors composing the product design context may be defined as follows: (1) customer context factors include consumer beliefs, values, practices, and demographics (e.g. wealth and age); (2) market context factors include aspects of competing products; and (3) usage context factors describe the situation in which the product will be used, such as weather and infrastructure (e.g. the state of roads, maintenance systems, central energy supply, and supply chains). Table 2 itemizes examples of product design context factors. Table 2: Examples of Product Design Context Factors Factors Examples Customer Context • Wealth • Safety expectations • Convenience expectations Market Context • Features of available products • Performance level and quality of available products • Cost of available products Usage Context • Energy supply cost, availability, and characteristics. • Infrastructure (e.g. transportation) available • Harshness of environment Preliminary research results [6] indicate product design context, in addition to primary functional requirements, are fundamental causes which give rise to both customer needs and product requirements in the product definition phase (as illustrated in Figure 1). The term “primary functional requirements” is used here to refer to the functions a product is designed to achieve independent of the design context. For example, a radio must in some way achieve the function of receiving and amplifying a radio signal, although how this is achieved by the product depends on whether the customer context factor of wealth is high or low. * Scale is from 0-5 with: 5=product must satisfy the need, 3=important to satisfy the need if possible, and 0=unimportant. † Customer needs capture what is required to satisfy customer expectations, which change over time with a changing market climate. Figure 1: Model of Information Flow for Customer Needs Gathering and Product Requirements Informing the product design process with a clear understanding of design context factors is particularly critical when the designer is unfamiliar with the context of the need. Engineers are often called on to design for frontier design environments (those unfamiliar to the designer). This occurs by default because engineers are a sub-set of society. Engineers design products which will be used by business people, artists, children, the illiterate, and other groups not represented among design engineers. Additionally, the importance multi-national companies place on positioning products in a global marketplace calls on engineers to design for customers in foreign countries and cultures. Frontier design environment – a product application environment that is unfamiliar to the product designer both in terms of personal experience and design expertise A special case of global design occurs when engineers in affluent societies create designs for use in severely resource-scarce environments, such as the human powered Freeplay Radio, initially targeted at rural African customers. Human interest groups suggest that over 2 billion “customers” are in need of appropriate technologies often characterized as simple, small-scale, labor-intensive, and efficient [7]. This potential market represents a significant engineering opportunity to improve the quality of life on a global scale. The engineering profession can boast great success in improving the quality of life through electrification, water supply, and electronics, to name a few [8]. The product definition step is critical for the success of any new product, and particularly problematic for frontier design environments. An opportunity exists to increase the success of products designed for frontier markets through formal recognition of product design context information during the product definition phase. The focus here is on the product usage context, leaving exploration of customer context and market context for future work. The product usage context (PUC) refers here to all factors relating to the environment in which a product will be used that may significantly affect its design. As shown in Table 2, PUC is one of three elements of the larger definition of product design context. Examples of PUC factors include: infrastructure (such as energy supply), how the product will be used (for what application), and the conditions the product will be exposed to (such as weather). Table 3 shows examples of differences in PUC factors which result in dramatic differences in the design of the product in question. * A case study of the Freeplay Radio design is included in [1]. C u s t o m e r M a r k e t U s a g e F u n c t i o n Customer Needs Product Requirements Table 3: Examples of Product Usage Context Differences Need (Product) PUC #1 PUC #2 Differences Cook food (Stove) Wilderness Domestic kitchen Size constraints, Energy supply Loosen/tighten nuts (Wrench) Space station Garage Ruggedness of use, Mass constraint Store ink writing (Paper) Office Clean room Allowable particle emissions Harvest crop (Scythe/Tractor) Rural village Commercial farm Maintenance, Prevailing wages Literature Review The current texts on design methods reviewed here all address the product definition phase to a greater or lesser extent. Cagan and Vogel [1] prescribe a number of methods for understanding “the user’s needs, wants, and desires” including: new product ethnography, customer scenario development, and lifestyle reference. The authors introduce SET Factors influencing the design of a product: social – culture and social interaction such as common hobbies or lifestyles; economic – the excess income people are comfortable spending; and technical – results of new discoveries. Otto and Wood [2] discuss gathering customer needs and competitive benchmarking as part of “understanding the problem”. They present supporting methods such as a: product mission statement, business case analysis, customer interviews and focus groups, activity diagram of product usage throughout the lifecycle, and Quality Function Deployment (QFD). Pahl and Beitz [3] emphasize the importance of “clarifying the task” through a requirements list which itemizes demands and wishes, both qualitative and quantitative. The authors present lists of questions and suggested categories for the design engineer to reference in order to facilitate defining accurate and complete product requirements. Ullman [4] organizes his discussion of the product definition phase around the QFD framework. Major steps include: identifying customers, identifying customer requirements through surveys and focus groups, benchmarking competing products, translating qualitative customer requirements into quantitative product requirements, and setting design targets. Ullman discusses the types of customer requirements and present a checklist to reduce the problem of the design engineer overlooking important product requirements. None of the above design methods were found to give significant attention to exploring the fundamental contextual factors leading to customer needs and product requirements, or a framework for categorizing, documenting, and correctly applying this information to a variety of design problems. The following paragraphs review research bearing significance to a discussion of product design contextual factors. Urban and Hauser [9] provide a detailed discussion of numerous techniques for: customer measurement, perceptual mapping, and benefit segmentation. The results of these techniques facilitate identification of a product opportunity, design of a product to fill the opportunity, and exploiting the opportunity through product positioning (primarily through marketing and branding). Although contextual factors are not explicitly dealt with, the effects of context would presumably be noticed as differences in customer needs and be identified as separate opportunities through benefit segmentation methods. LaFleur [10] proposes a general framework for describing engineering design problems in terms of fundamental variables. Included in these variables are “environmental constraints” and “environmental conditions.” The engineering environment is divided into four categories, including the “Application Environment (APP)” described as the “actual situation the device will encounter; real conditions and constraints, actual tasks to perform and real behavior.” The Application Environment is described as a large source of public domain information, which is “fuzzy due to real complexities.” Additionally, this work mentions the role of experience in the design process, noting that this experience “can be tracked and represented as information,” thus making an experienced designer’s knowledge accessible to others. Crawley and Holland [11] present the “Design, Development and Marketing of Solar Lanterns” for the rural poor of African countries. They specifically address Kenya, which has a large population without hope of access to electricity in the near future; more than 90% of households use kerosene lighting, and 70% also use scarce cash supplies to buy batteries. They employed focus groups and general discussions to gather information about what customers wanted in a solar lantern. They noted the importance of: (1) picking groups not dominated by a few dominant members, (2) holding surveys during the day for travel safety of participants, and (3) focusing on individuals with incomes similar to the target customers, who often had significantly different spending patterns than wealthier individuals. In general, the authors note that for companies in developing countries, product development is expensive and high-risk. They indicate that in these situations conventional research techniques for gathering customer needs are often incomplete and inaccurate in accounting for lifestyles and culture. A chapter on international market research [12] notes that unfamiliarity with a foreign country is a hazard faced by market researches which can cause ambiguity and false conclusions. Common blunders originate from unstated assumptions which may differ from one country and culture to another. Some kinds of market research in certain countries are not feasible. “... particularly in developing countries – it is virtually impossible to design an adequate quota sample ...”due to lack of social structure definition, or lack of knowledge. Interviews do not work in some settings; for example, “Question-and-answer interaction with a strange can sometimes seem strange, even uncomfortable or threatening.” Therefore there is “no substitute for close familiarity with the local culture” [italics added]. Even in some developing countries the costs of market research have risen to nearly European levels, which increases the importance of economical solutions to overcome the listed problems. Additionally, [11] advises that when tapping global markets, multinational companies must be wary of errors on two extremes: attempting to standardize the product for significantly different markets, or excessive customization for significantly similar markets. A balance must be struck which properly accommodates real and important differences, without unnecessarily undercutting economies of scale through standardization. Examples of major differences faced when political and/or cultural boundaries are crossed include: language, ethnic, religious, social structure, tradition, literacy, income patterns, geography and climate, infrastructure, product distribution, advertising, and legal climate. Chen et al. [13] predict that “... multicultural factors are the most difficult issues for organizations to address ... [and will be a] future direction in NPD.” They address the need for research in this area, commenting “... there are few successful or effective techniques available for the evaluation of multicultural factors in customer requirements.” This paper proposes a system employing laddering technique and radial basis function (RBF) neural network to address the problems of multicultural barriers to customer needs gathering. A mobile phone design case study is included. The cultural factors addressed are primarily dealing with the customer context. Some design research addresses the consideration of “culture” in the design process. Culture may be defined as the customary beliefs, values, social forms, and material traits of a group of people that are learned from preceding generations (author’s adaptation from [14]). Ellsworth et al. [15] reports on the “effects of culture on refrigerator design.” This paper does not define culture, but references the “needs and values” of customers which differ from place to place. The authors build a case for improved cultural understanding among design engineers, stating that products will be more successful worldwide as design engineers account for cultural needs. The authors propose the development of a Design for Culture (DfC) methodology, citing a dearth of literature as evidence of a lack of attention to the subject, and suggesting that cultural considerations must include not only marketing but also design. They suggest studying the use of similar products across different cultures to begin development of such a method. Refrigerators were chosen for this study because they are in widespread use globally and the designs have stabilized with distinct differences in various countries. The paper itemizes a number of macro physical differences (such as volume, energy efficiency, and construction) in refrigerators used in the US, Europe, Japan, and Brazil, and comments on the apparent cultural reasons for these differences. The authors conclude by suggesting the following categories of cultural aspects to account for: aesthetic appeal, cultural habits (e.g. tendency to snack), traditions, available resources, and physical environment. * New Product Development Donaldson [16,17] proposes various items to improve product development for developing countries, and comments extensively on the particular barriers and problems associated with designing for this context. Some of Donaldson’s findings may be generalizable to other frontier design environments. The literature reviewed here relating to product design context is far from complete, and the authors reviewed often emphasize the need for greater attention to this area. No research was found that distinguishes among the effects that market, customer, and product usage context have on product definition. Further, no work was found to provide a framework for formally categorizing, documenting, and correctly applying contextual information to a variety of design problems. The theoretical framework proposed above for design contextual factors is foundational to the hypotheses and research objectives which follow. Primary Hypothesis and Sub-Hypotheses To satisfy customers and achieve market success, an engineered product must be designed to match the intended design context(s). It is asserted here that successful products in mature markets have followed a set of implicit rules which represent necessary (but not sufficient) criteria for success. This research seeks to discover and document an understanding of some of these rules constraining product success, and convert them into actionable design insights. The study begins by documenting and analyzing the product definition information (customer needs and product requirements) for a functional family of products (products performing the same primary function). This product definition information will then be linked to information about the usage context(s) each product is matched with. It is hypothesized that actionable design insights gleaned from the synthesis of this information will result in greater success for those designing for frontier design environments. Primary Hypothesis: When performing original design for product needs in a design context outside their experience and expertise, engineers generate a more appropriate product requirements list (as judged by field experts) when equipped with the following: (1) knowledge encapsulation modules providing familiarity with the target product usage context, (2) Ashby-style plots graphically comparing products (successful in the target usage context) on the basis of normalized key performance metrics, and (3) a Design by Analogy method indicating how similar needs have been solved in a usage context with one or more identical characteristics. Sub-Hypotheses 1. Product definition information determined through reverse engineering will show distinct differences in both customer needs and product requirements among products* in a given functional family. The products shown to have distinctly different product definitions will be found to be matched with distinctly different appropriate usage context(s), with the market and customer contexts held as constant as possible. 2. Products from differing functional families matched with a given usage context will show similar values of normalized key performance metrics for the context. For a backpacking context, for example, mass and volume are both key performance metrics. Therefore both lights and stoves designed for backpacking are expected to have low normalized masses and volumes (e.g. less than 0.2.) * Throughout this study, products studied are those with proven success in a mature market. † The hypothesis could also be applied to selection design, in which case the experimental test would be an evaluation by field experts of the appropriateness of the product selected by the design engineer. ‡ Stated less formally: when two products designed to perform the same function for similar customers in similar markets are found to be very different, these differences can be convincingly explained in terms of differences in the usage context matched with each product. 3. Products which solve the energy functions in similar ways exhibit similarities in certain normalized key performance metrics. For example, products which solve the “import energy” and “convert energy” function with disposable batteries are expected to have high normalized capital intensiveness ($/unit function). Supporting Objectives and Approach The proposed research plan is organized around the following research objectives; the first three correspond to the sub-hypothesis and the fourth to the primary hypothesis: 1. Reverse engineer products in multiple functional families to document the product definitions and appropriate usage contexts. 2. Investigate the correlation between characteristics of a product’s appropriate usage context(s) and normalized key performance metrics. 3. Investigate the correlation between a product’s solution of the energy functions and normalized key performance metrics. 4. Convert the information gleaned from the previous objectives into actionable design insights in the forms of: knowledge encapsulation modules, Ashby-style plots, and a Design by Analogy method. Provide these tools to engineers designing for a design context outside their experience and expertise, and compare the product requirements they generate to a control group. Figure 2: Example of Representative Products from a Functional Family 1. Reverse engineer products in multiple functional families to document the product definitions and appropriate usage contexts. Addressing this objective begins with selecting a set of representative products from a functional family. The functional family should contain a mature set of products dominated by mechanical engineering energy flows and addressing a basic need, such as “broadcast light, with mobility” (Figure 2) or “lift water.” Each product will be reverse engineered to uncover the product definition (customer needs and product requirements). This information will be documented in a QFD format (Figure 3 and Figure 4), according to the following steps: • Gather customer needs through interviews, product literature, and experiencing the product. • Identify and characterize the product usage context(s) the product is appropriate for through customer interviews and follow-up surveys. * Benchmarking data is shown in Figure 4 for a family of products. For this study, the measurements of a given product will be considered to show the design targets representing part of the product requirements. • Measure customer perceptions of how well each product fulfills the identified customer needs. Semantic laden needs such as “easy to use” and “safe” will be measured through a newly developed semantic inquiry survey tool. • Map customer needs to product requirements using the QFD methodology. Aggregate metrics which may traditionally be overlooked will be hypothesized; such as capital intensiveness, labor intensiveness, and energy intensiveness. • Benchmark the products by measuring the identified product requirement metrics. • Validate the mapping of customer needs to product requirements (shown in the matrix labeled “needs vs. metrics”) using customer perception measurements. If the identified product requirements show the benchmarking data is inconsistent with customer perceptions, this indicates the product requirements are incorrect or incomplete, and further iteration is needed. • Prioritize product requirements according to the relative importance of customer needs associated with each, to identify those which are key performance metrics. Confirm and modify these based on further customer interviews. • Sub-hypothesis #1 will be supported if the expected differences are found among both the product definitions and matched usage context(s) for products within the same functional family. Figure 3: Layout for Product Definition (shown in QFD format) * Note that whether a given metric is a “key performance” metric depends on the usage context.